Method and Apparatus for Expedited Rental Vehicle Reservation Creation Following a Previous Reservation

ABSTRACT

A method and apparatus are disclosed for expediting the ability of a customer to book a new rental vehicle reservation after booking a previous rental vehicle reservation. A link can be provided on a screen such as a confirmation page for a previous rental vehicle reservation that, upon customer selection, causes a new reservation transaction to be automatically loaded with data from the previous rental vehicle reservation.

CROSS-REFERENCE AND PRIORITY CLAIM TO RELATED APPLICATIONS

This application is a divisional of pending U.S. patent application Ser.No. 10/505,683, filed Aug. 25, 2004, entitled “Method and Apparatus forCustomer Direct On-Line Reservation of Rental Vehicles IncludingDeep-Linking”, now U.S. Pat. No. ______, which is a national stage entryof PCT patent application PCT/US03/18553, filed Jun. 13, 2003, which isa continuation-in-part of pending U.S. patent application Ser. No.10/172,481, filed Jun. 14, 2002, entitled “Method and Apparatus forCustomer Direct On-Line Reservation of Rental Vehicles”, the entiredisclosures of which are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to the automated processing and booking ofreservation transactions conducted over a computer network between acustomer and a reservation booking entity. In particular, the presentinvention relates to the on-line reservation of rental vehicles. Evenmore particularly, the present invention relates to the reservation ofrental vehicles over the internet through a consumer accessing adedicated web site.

BACKGROUND

In the past decade, the use of the Internet in connection withcommercial activities (so-called “e-commerce”) has exploded intovirtually all areas of the business world. Among the businessesutilizing the Internet for e-commerce purposes have been car rentalbusinesses.

One of the ways that the car rental industry has utilized the power ofthe Internet is through on-line reservation booking. In addition to themany travel web sites, another way for a consumer to book a reservationover the Internet using an Internet-connected computer is to interactwith a server maintained by the entity that books the reservation. Tosuccessfully complete a reservation transaction, the customer mustgenerally provide the server with 3 or 4 basic types of information: (1)temporal information—when and for how long the car rental is needed(typically entered as pick up and return dates), (2) locationinformation—from which branch of the rental car company the rental caris desired to be obtained, (3) vehicle information—what type of vehicleis needed, and optionally (4) customer information—the customer's ageand/or name.

With these informational needs in mind, various websites dedicated toon-line booking of car rental reservations have been developed. Suchon-line reservation websites guide the customer through the reservationprocess so that the customer provides the server with the informationnecessary to complete a reservation transaction. Thereafter, the servercan create the reservation and post it to the rental car company'sdatabase. However, the current on-line reservation websites have failedto guide customers through the reservation process in a manner thatprovides both a high degree of user-friendliness and flexibility.Because of the rigid navigational structure of current on-linereservation websites, it is believed that on-line reservation processinghas failed to reach its full potential in the marketplace.

FIGS. 1( a)-(d) illustrate an example of a conventional on-linereservation booking process. The customer accesses a page having a formthat includes a plurality of fields in which he/she can enter data. Somefields are required for the reservation to be booked, some are not(required fields are denoted by the *). If the customer submits data forless than all of the required fields, the form is returned to thecustomer with an indication that he/she must fill out all requiredfields to successfully submit a reservation. In the example of FIG. 1(a), it can be seen that the customer has entered “St. Louis Airport” inthe required location field, but has left all other fields blank. Whenthis form is submitted, the form of FIG. 1( b) is returned. Errorindicators are placed adjacent to the blank required fields, and anerror message instructs the customer to fill all required fields. If theform of FIG. 1( c) represents the result of the customer's next attemptto submit a reservation, it can seen that the customer has now failed toinclude his/her age in the form. The confirmation form of FIG. 1( d)will only be provided to the customer after an age is entered in the agefield. The confirmation page of FIG. 1( d) is only presented to thecustomer after the customer has submitted all required fields and theserver has determined that a reservation is possible given the datasubmitted in the required fields (i.e., that a luxury sedan is availablefor rental at the St. Louis Airport branch from Aug. 1, 2002 throughAug. 3, 2002 to a 35-year old person).

Because of the different types of data needed to book a reservation (asexemplified by the required fields in the forms of FIGS. 1( a)-(c)), theon-line rental vehicle reservation process can be thought of as amulti-stage process, wherein each stage corresponds to receipt of aparticular type of necessary reservation information from the customer.That is, one stage relates to obtaining temporal information from thecustomer, another stage relates to obtaining location information fromthe customer, another stage relates to obtaining vehicle informationfrom the customer, and yet another stage relates to obtaining personalinformation from the customer.

Many current on-line rental vehicle reservation websites guide customersthrough these stages one stage at a time. That is to say, the customeris first presented with a page requesting that temporal information forthe reservation be provided. After the customer transmits the requestedtemporal data to the server, the server responds by presenting thecustomer with a page requesting that location information for thereservation be provided. After the customer transmits the requestedlocation data to the server, the server responds by presenting thecustomer with a page requesting that vehicle information be provided,and so on until the server receives all types of necessary data. Onceall types of necessary data are received, the server presents thecustomer with a verify page that summarizes the entered data. If thecustomer wishes to change any of the entries, that customer is droppedback to the stage where revision is desired. In simplistic systems, thecustomer must thereafter re-supply the server with the information forany stages downstream from the revised stage. In more advanced systems,the customer can be returned to the verify page after entering therevision data. FIG. 2 illustrates such a conventional linear process(the dashed line indicating the improved revision process).

Such conventional techniques suffer from a shortcoming in that acustomer who realizes that an error was made in entering stage 1 data(for example, entering the wrong starting date for the rental) but doesnot realize the mistake until stage 2, must wait until all stages arecomplete before getting the opportunity to correct the mistake. Becauseof this inconvenience, customer frustration may occur which could leadto the customer leaving the site without completing the reservation.Also, such conventional reservation techniques require the customer tocomplete reservation stages in a fixed order defined by the reservationbooking entity and not the customer. Thus, customers typically do nothave the freedom to complete stages in the order they may desire.

Another reservation booking process known as of the filing date hereofis shown in FIG. 3. Rather than forcing the customer to first complete aparticular stage before proceeding to a next stage, the customer isallowed to first complete any of a plurality of stages (but not thevehicle stage—which requires prior completion of both the time stage andlocation stage), and then proceed through each individual remainingstage in a single-step fashion. While such a reservation system givesthe customer the partial freedom to select the order in which stages arecompleted, it still requires the customer to complete the reservationprocess sequentially using a fixed number of minimum data exchanges.That is to say, for each stage, the customer must access the pageassociated with that stage before proceeding to a page associated withthe next stage. This shortcoming may unnecessarily draw out thereservation process, thereby adding to customer frustration and possibleloss of a reservation.

Another feature of a competitor's on-line reservation system is asummary section that is provided on the left hand side of each pageassociated with a stage (the right hand side of each page is dedicatedto prompting the customer to enter the data for the stage associatedtherewith). The summary section lists the stage data entered by thecustomer. As the customer completes stages, the summary section isupdated with the new data entries. However, the competitor's summarysection is a read-only summary. It is not interactive to allow thecustomer to directly select a data entry he or she may wish to revise.If the customer, upon reviewing the summary section, decides that astage needs to be re-visited to revise the data corresponding thereto,the customer must correlate which stage is associated with the dataneeding revision and then identify a tab or other pointer on the righthand side of the page and select it to re-visit the stage associatedwith the data needing revision. FIG. 4 illustrates this aspect of thecompetitor's reservation system. Because of the potential customerconfusion that may be created as customers navigate through such anon-line reservation system, increased customer dissatisfaction maydevelop.

Log file research and usability tests have shown that customers willabandon websites as a function of the website's user-unfriendliness andinconvenience. As such, to maximize the potential of their e-commerceinvestment, it is highly important that reservation booking entitiesdevelop an on-line reservation system that smoothly guides the customerfrom start to finish while allowing those customers to proceed at theirown desired pace with a minimum of inconvenience. This is especially thecase due to the inherent uncertainty of speed and connectivity of theInternet. In other words, requiring potential customers to accessincreased numbers of menus or displays increases the amount of timerequired to successfully complete a reservation. These studies haveshown that user drop out increases as a function of time, so designing aweb site which perhaps is easily implementable in HTML or otherprogramming code may well lead to a rigid, single path architecture thatis not optimized for user friendliness, minimal data entry, and minimaldisplay access steps.

SUMMARY

Toward this end, the inventors herein have developed an on-linereservation transaction system wherein the customer can complete thestages of the reservation transaction via a customer-determined path,and not according to a strictly defined, straight-line architecture.

According to one aspect of the parent invention, disclosed herein is amethod of processing a reservation transaction between a customer andreservation-booking entity via a computer network connecting a customercomputer with an automated reservation transaction processor, thereservation transaction requiring submission of at least three differenttypes of reservation data from the customer for successful completionthereof, each reservation data type having one of a plurality ofdifferent values, wherein each reservation data type value is dependentupon other reservation data type values, the method comprising: (a)displaying a page on the customer computer, the page including (1) arequest that the customer submit values for at least two of thedifferent data types, and (2) for each requested data value, a datasubmitter through which the customer can submit a data value to theautomated reservation transaction processor; (b) receiving data at theautomated reservation transaction processor from the customer computerthat corresponds to a submission of a data value for at least one of thedata types; (c) determining from the received data at least one datatype, if any, that remains unsubmitted; (d) if any unsubmitted data typeis determined to remain, determining, on the basis of theinterdependence of the different data values for the differentreservation data types, a list of remaining acceptable values for the atleast one unsubmitted reservation data type; (e) displaying another pageon the customer computer, the another page including (1) said at leastone determined list of acceptable data submission values, and (2) foreach said determined list, a data submitter for submitting at least oneof said acceptable values to the automated reservation transactionprocessor; and (f) repeating steps (b) through (e) as necessary untilall required data types are successfully submitted to the automatedreservation transaction processor, thereby completing the reservation.

The reservation transaction is preferably a rental vehicle rentalreservation, wherein the types of necessary data comprise temporalinformation, location information, and vehicle information. Additionaltypes of necessary data types may include customer age information andother customer personal information (such as name, phone number,insurance, etc.).

The data values for the reservation data types are said to be dependentupon each other because it is not necessarily the case that all possiblecombinations of the different values for each reservation data type willbe acceptable to complete a reservation. That is, in a given reservationtransaction, a particular data value for a particular data type mayrestrict the range of acceptable values for other data types. Forexample, the value of “luxury” for vehicle type may display a range oflocation values but restrict the range of acceptable location valuesfrom locations 1-10 to only locations 3 or 4; or the value of Jul.10-14, 2002 for starting/end time and the value of Location X forlocation may restrict the range of acceptable values for vehicle typesfrom all vehicle types to only “economy” and “compact”. Thus, the rangeof acceptable values for each reservation data type are dependent uponavailability given any previous data value entries for other reservationdata types. At the same time, the user may choose to change one of thelimiting data values to thereby change the resulting range of acceptabledata values for other data types. Because the parent invention narrowsthe customer's data submission options to a list of acceptable valuesfor an unsubmitted data type on the basis of what values are acceptablefor successful completion of a reservation given the previous data valuesubmissions for the other data type, customers are guided toward makingchoices that maximize the likelihood of successfully booking areservation with minimal customer dissatisfaction.

According to another aspect of the parent invention, herein is discloseda method of processing a reservation transaction between a customer anda reservation-booking entity via a computer network connecting acustomer computer with an automated reservation transaction processor,the reservation transaction requiring a plurality of customer-enteredpieces of information that are necessary for successful completionthereof, the method comprising displaying a page on the customer'scomputer, the page being configured with (1) at least one field for thecustomer to submit a piece of necessary information, and (2) a summarythat includes (a) a list comprised of any pieces of said necessaryinformation previously submitted by the customer and (b) at least oneselectable edit link for requesting a data submitter for entering atleast one revised data value for at least one piece of said necessaryinformation.

The use of such an interactive summary on the interactive web pages ofthe parent invention allows customers to quickly and easily enter anychanges to the previously-submitted data.

According to yet another aspect of the parent invention, deep-linking isprovided for customers seeking to book a reservation from a promotionallink or from a corporate account. The promotion corresponding to apromotional link that may be selected by a customer may have one or morepromotion conditions, each promotion condition corresponding to aparticular data value or range of data values that the customer mustchoose for a particular reservation data type. For example, a promotionoffering a reduced rate may only be valid for a single vehicle type ormay only be valid for a limited time. Similarly, a corporate account mayinclude limiting parameters analogous to promotion conditions. With thepresent invention, when a customer selects a promotional link or aparticular corporate account, that customer is deep-linked into thereservation booking process such that the data values for any data typethat correspond to a promotion condition (or a corporate accountparameter) are identified in the accompanying text. Also, anyreservation data types corresponding to promotional conditions (orcorporate account parameters) have their data values set equal to thoseconditions/parameters. Should the customer submit a data value thatviolates a promotion condition (or corporate account parameter), thenthe parent invention notifies the customer of this situation andpresents him/her with an option to revise the data value causing theviolation of a promotion condition/corporate account parameter.Instructional text may also be found on subsequent pages. Alternately,the customer may elect to continue the process and not take advantage ofthe promotion or move off the corporate account.

By deep-linking into the website those customers who are seeking to takeadvantage of an offered promotion (or an available corporate account),the parent invention avoids inconvenience to the customer that wouldresult from requiring the customer to first learn what data values needto be entered to satisfy the conditions of the promotion and thenentering those values. Those steps are bypassed by deep-linking thecustomer to a point in the reservation booking process where data valuesrelating to promotional conditions are automatically set to theconditional values. Also, by notifying the customer when a submitteddata value for a reservation data type violates a promotion condition(or corporate account parameter) and by giving the customer the optionto accordingly revise that data value, the parent invention avoids thecustomer dissatisfaction that may arise from the customer losing out ona desired advantage because of an unintentional violation of a promotioncondition or corporate account parameter.

As part of this deep-linking concept, repeat users such as regularcustomers and on-going business partners of the reservation bookingentity can be provided with a URL that is operative to deep-link acomputer user into the reservation server site in accordance with acorporate account maintained with the reservation booking entity by therepeat user. This URL can be placed on the repeat user's computer system(such as an Intranet site) as a hyperlink that can be selected bycustomers who want to book a reservation from that computer system,wherein the reservation takes advantage of any deals or rates that areavailable through the repeat user's account.

Further, it is worth noting that travel agents (or travel agentorganizations) can act as a business partner who uses a corporateaccount. Further still, travel agents can be provided with identifiersthat allow the system to track and assess commissions to the travelagents for booked reservations as may be appropriate.

Further still, according to another aspect, a user interface can be usedto define the parameters of a corporate account, customer account, orpromotional offer. Such an interface provides fast, flexible controlover account parameters that are tailored to the wishes of, for example,a business partner for whom a corporate account is created.

According to yet another aspect of the parent invention, the parentinvention can be implemented to use web services for data exchangesbetween the customer computer and the reservation booking website. Withweb services, XML messages using standard formatting are passed betweenthe customer computer and reservation booking website. XML messagingprovides for increased speed and ease of connection between the customercomputer and the reservation booking website, and further offersimproved reuseability and a substantial decrease in the configurationchanges needed for the customer computer-to-reservation booking websitecommunications.

The parent invention further provides an efficient use of a user's timeand network connectivity, by minimizing the required amount ofinteractivity, and movement of data/displays from the reservationbooking website and the customer's computer. As is known in the art,delays are commonly experienced on the Internet due to the requiredtransmission of large amounts of data to create displays so thatminimizing the number of displays must necessarily speed up the processof a user making an Internet reservation.

Still another aspect of the parent invention is the design feature thatcreates a summary section with hyperlinks for a user to convenientlyclick and move to a display to change the corresponding data needed tocomplete the reservation. This summary is further advantaged byoccupying less than all of the display screen. This feature of theinvention focuses the user on the single most important task at hand,i.e. that of completing the reservation in a manner acceptable to theuser, with the correct information entered, and with perhaps the mostuser-friendly and intuitive method for correcting/changing anyinformation needed for completing the reservation. The invention thusadapts the website architecture to the user's needs, and points everyuser action towards completing the reservation to thereby maximize the“completion” rate of reservations achieved compared to the number ofusers accessing the website.

In accordance with an aspect of the present invention, the inventorsdisclose a method of processing a rental vehicle reservation transactionbetween a customer computer and a rental vehicle reservation-makingentity via a rental vehicle reservation booking server accessed by acustomer computer over a computer network, the method comprising: (1)receiving reservation data from the customer computer, (2) booking areservation transaction in accordance with the received reservationdata, and (3) communicating data to the customer computer for displaythereon after the reservation transaction has been booked, wherein thecommunicated data includes a link that is selectable by the customer tocreate a new reservation transaction, wherein the new reservationtransaction is pre-loaded with the received reservation data, andwherein the method steps are performed by the server.

The inventors have further disclosed an apparatus for processing arental vehicle reservation transaction with a customer computer, theapparatus comprising a server configured for access by a customercomputer via a network, the server configured to: (1) receivereservation data from the customer computer, (2) book a reservationtransaction in accordance with the received reservation data, and (3)communicate data to the customer computer for display thereon after thereservation transaction has been booked, wherein the communicated dataincludes a link that is selectable by the customer to create a newreservation transaction, wherein the new reservation transaction ispre-loaded with the received reservation data.

These and other features and advantages of the parent and presentinventions will be in part apparent and in part pointed out in thefollowing description and referenced figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a prior art technique by which a reservation bookingwebsite obtains reservation data from a customer;

FIG. 2 illustrates another prior art technique by which a reservationbooking website obtains reservation data from a customer;

FIG. 3 illustrates yet another prior art technique by which areservation booking website obtains reservation data from a customer;

FIG. 4 illustrates a known technique for providing a customer with asummary of existing reservation data as the customer proceeds throughthe various stages of the reservation booking process;

FIG. 5 illustrates an overview of the reservation data gatheringtechnique of the parent invention, wherein 3 types of reservation dataare needed;

FIG. 6 illustrates a preferred architectural overview for the parentinvention;

FIG. 7 illustrates the preferred automated reservation transactionprocessor in more detail;

FIG. 8 illustrates a preferred technique for how the parent inventionprocesses data received from the customer;

FIGS. 9-12 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from thehome page;

FIG. 13 illustrates a preferred navigational path for the reservationbooking process of the parent invention starting from a page designed toobtain general locational information from the customer;

FIGS. 14-15 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to obtain a branch selection from the customer;

FIGS. 16-17 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to obtain a vehicle selection from the customer;

FIGS. 18-19 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to provide the customer with detailed information about aselected vehicle;

FIGS. 20-23 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to provide the customer with detailed information about aselected branch;

FIG. 24 illustrates a preferred navigational path for the reservationbooking process of the parent invention starting from a page designed toobtain pertinent personal information about the customer;

FIGS. 25-26 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to allow the customer to review and verify the reservation dataprior to booking;

FIG. 27 illustrates a preferred navigational path for the reservationbooking process of the present invention starting from a reservationconfirmation page;

FIGS. 28-29 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to allow the customer to change the reservation time;

FIG. 30 illustrates a preferred navigational path for the reservationbooking process of the parent invention starting from a page designed toallow the customer to change the age data;

FIG. 31 illustrates an overview of how the parent invention allows acustomer to deep-link into the reservation booking process upon theselection of a promotional link;

FIG. 32 illustrates the promotional deep-linking aspect of the parentinvention;

FIG. 33 illustrates how the parent invention allows a customer who isfollowing a promotional path to make informed decisions when enteringdata to avoid violating the conditions of the promotion;

FIG. 34 illustrates an overview of how the parent invention allows acustomer to deep-link into the reservation booking process with use of acorporate account;

FIG. 35 illustrates the corporate account deep-linking aspect of theparent invention;

FIG. 36 illustrates how the parent invention allows a customer who isfollowing a corporate account path to make informed decisions whenentering data to avoid violating the parameters of the corporateaccount's profile;

FIG. 37 is a screenshot of a preferred home page (H) for the parentinvention;

FIGS. 38-41 are screenshots of preferred “choose location” pages(CL1-CL4) for the parent invention;

FIGS. 42-43 are screenshots of preferred “choose vehicle” pages(CV1-CV2) for the parent invention;

FIGS. 44-45 are screenshots of preferred “vehicle details” pages(VD1-VD2) for the parent invention;

FIGS. 46-49 are screenshots of preferred “branch details” pages(BD1-BD4) for the parent invention;

FIGS. 50( a)-50(b) are screenshots of a preferred “renter information”page (RI) for the parent invention;

FIGS. 51-52 are screenshots of preferred “verify” pages (V1-V2) for thepresent invention;

FIG. 53 is a screenshot of a preferred “confirmation” page (Conf) forthe present invention;

FIGS. 54-55 are screenshots of preferred “change time” pages (ChT1-ChT2)for the parent invention;

FIG. 56 is a screenshot of a preferred “change age” page (ChA) for theparent invention;

FIG. 57 is a screenshot of a preferred “stripped down home page” page(SH) for the parent invention

FIG. 58 is a screenshot of a preferred “after hours” page (AH) for theparent invention;

FIGS. 59-61 are screenshots of preferred “apology” pages (APOL1-APOL5)for the parent invention;

FIG. 62 is a screenshot of a preferred “cancel reservation” page(Cancel) for the parent invention;

FIG. 63( a) is a screenshot of a preferred “promotional parametersnotice” page (Notice) for the parent invention;

FIG. 63( b) is a screenshot of a preferred “corporate account parametersnotice” page (Notice) for the parent invention;

FIG. 64 is a screenshot of a choose location page, wherein the list ofavailable branch locations has been restricted to airport branchlocations;

FIG. 65 is a screenshot of a branch location search page;

FIG. 66 is a screenshot of a list of branch locations returned after auser has entered search criteria on the page of FIG. 65;

FIG. 67 is a screenshot of a branch location details page that isdisplayed upon selection of a branch location from the page of FIG. 66;

FIG. 68 illustrates a preferred format for a “get rates” web servicerequest and response;

FIGS. 69( a) and (b) illustrate a preferred format for a “createreservation” web service request and response;

FIG. 70 illustrates a preferred format for a “get reservation” webservice request and response;

FIGS. 71( a) and (b) illustrate a preferred format for a “modifyreservation” web service request and response;

FIG. 72 illustrates a preferred format for a “cancel reservation” webservice request and response; and

FIG. 73 illustrates a preferred GUI for defining the parameters of anaccount or promotional offer.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 5 illustrates the basic navigational structure for the reservationbooking website of the parent invention. In the example of FIG. 5, thedifferent types of data needed from the customer to successfully book arental car reservation are: (1) temporal data (T)—such as the startingand ending dates for the reservation, (2) location data (L)—such as anidentification of the particular branch of the rental car company fromwhich the customer seeks a car rental reservation, and (3) vehicle data(V)—such as the type of vehicle the customer wants to rent (economy,midsize, luxury, etc.). The customer can submit values for these datatypes to the reservation booking entity via a customer-determined numberof stages. Each box in FIG. 5 represents a page of the website, and thetext within each box represents the data types for which the pagerequests data values from the customer. Each arrow indicates asubmission of data by the customer, and the text adjacent each arrowrepresents the type(s) of data being submitted.

The customer, depending on his/her desires, can either submit all datavalues for all necessary data types to the reservation booking entityvia a single data exchange 104, two data exchanges 102, or insingle-step fashion via three data exchanges 100. Once the reservationbooking entity has received all necessary data from the customer, averify page is presented from which the customer can review his/her dataentries and thereafter book the reservation if all is accurate.

In the single data exchange 104 wherein the customer submits temporal,locational, and vehicle data at the same time, the reservation bookingentity must consult a database to determine whether a reservation havingthose data values is possible. If not, the customer will be guided toamend one or more of the reservation data entries.

In the two-step data exchange 102, the reservation booking entity canprocess the double submission (TL, TV, or LV) to determine how to moreaccurately guide the customer through the process. For example, if bothT and L are submitted at once, the reservation booking entity knows thatvehicle data is still needed, but because both T and L data have beensubmitted, it can refine the customer's options for selecting vehiclesto only those vehicles available at the selected time from the selectedlocation. This aspect of the invention is taken one step further in thethree-step data exchange 100. On each submission of data, thereservation booking entity processes the submitted data on the basis ofthe data values interdependent to refine the number of acceptable datavalue options for the remaining data types.

FIG. 6 illustrates a preferred architecture for the parent invention. Aplurality of customer computers 210 connected to a network 204 (such asthe Internet) and using web browsing software can access a reservationbooking website hosted by automated reservation transaction processor150. Automated reservation transaction processor 150 can be any computerthat is network connectable. Preferably, the processor 150 comprises anapplication server 200 (or application servers for redundancy purposes)a web server (or servers) 200, a customer/promotional database 208, anda business database 206. The application server 200 (1) interacts withthe customer computers via web server 202 (or web servers) to obtainreservation data therefrom, (2) interacts with business database 206 viaa connector interface such as Tuxedo, and (3) interacts with acustomer/promotional database 208 via a connector interface such asJDBC. Business database 206 stores all of the data pertaining to therental car company's branch locations, vehicle inventories, pricing,etc. Customer/promotional database 208 preferably stores the profiles ofany registered customers, the profiles of any corporate accounts, anddata relating to any rental promotions being offered by the company.

FIG. 7 illustrates the automated reservation transaction processor 150in greater detail. Application server 200 preferably runs WebLogic 6.1software 250 and interfaces with web server 202 (preferably an Apacheweb server 242) via a servlet 220 and a Java Server Page (JSP) 222,preferably using Struts architecture. The servlet communicates with apersonalization application programmer's interface (API) 228 to storeand retrieve customer profiles and a promotions API 230 to retrievepromotional data. The APIs 228 and 230 link with EJB connector logic 232which in turn links with JDBC connector logic 234. The JDBC connectorlogic 234 allows the application server 200 to communicate with databaseserver 208 (which is preferably an Informix database 236). The serveralso communicates with the business database 206 via EJB connector logic224 and WebLogic Tuxedo connector 226. The business database server 206is preferably an AS/400s implementing Tuxedo services 240 and Tuxedoconnector 238.

Servlet 220 performs the major decision-making tasks for the reservationbooking process of the parent invention. Servlet 220 interacts with thedatabases to gather necessary information for both (1) determining whichpage should be constructed by the JSP 222, and (2) the particular datathat should appear on the page. Upon reference to the navigationalcharts and screen shots of the succeeding figures, a programmer havingordinary skills can readily implement the programming needed toimplement the parent invention, particularly the servlet 220 and JSP222. Also, as one of ordinary skill in the art would readily recognize,any of a number of servers and software platforms can be used inconnection with the parent invention. As such, the parent invention isin no way limited by the configurations shown in FIGS. 6 and 7.

FIG. 8 is a flowchart illustrating how the application server 200processes data received from customers. At step 8.1, the applicationserver receives a data submission from a customer computer. Using FIG. 5as an example, this data may relate to T, L, or V. At step 8.2, theapplication server creates a reservation transaction for the customercomputer and stores the received data therein. Next at step 8.3, theapplication server processes the received data to determine whatinformation is still needed from the customer to complete a reservation,and what information the customer needs to make a meaningful decisionwhen deciding what to choose for the remaining data. To make suchdecisions, the servlet 220 interacts with the business database 206. Forexample, if servlet has received T and L data from the customer, theservlet determines that V data is still needed and queries databaseserver 206 for all vehicles available from the selected L at theselected T. Preferably, the servlet also queries the database foradditional information pertaining to the available vehicles, such as aprice and a general description (both of which can be included in thepage to be built and sent to the customer). At step 8.4, the servletthen interacts with JSP 222 to build a web page with necessaryinformation and hyperlinks that allow the customer to make a furtherdata submission that will at least partially satisfy at least oneremaining reservational data need. Thereafter, at step 8.5, the customercomputer accesses the built page and the process repeats itself asadditional data submissions are received from the customer computer.

In addition to using traditional data exchanges between the customercomputer and the website over the Internet, the parent invention mayalso be implemented with web services to use XML data exchangesaccording to the Simple Object Access Protocol (SOAP). FIGS. 68 through72 illustrate the XML formats for a preferred web servicesimplementation of the parent invention. Under this implementation,various business partners of the reservation booking entity are providedwith URLs for these services. Through these URLs, employees or personsauthorized by the business partner may book reservations via the websiteusing the web services shown in FIGS. 68-72 and described below. A listof the IP addresses of the business partners having authorization to useweb services is preferably maintained so that incoming service requestscan be checked on the basis of IP address to ensure that only the webservices business partners gain access to these services. However, itshould be understood that the parent invention can also be implementedwith limited access to web services beyond a limited group of businesspartners as well as be implemented with unrestricted access to the webservices.

It is preferred that the customer communicating with the reservationbooking website pass data to the web services via the Open TravelAlliance (OTA) 2002 XML standard using SOAP. Further, it is preferredthat the following web services be provided: a “Get Rates” service, a“Create Reservation” service, a “Get Reservation” service, a “ModifyReservation” service, and a “Cancel Reservation” service.

FIG. 68 illustrates the preferred formatting for the “Get Rates” servicerequest and response. The “Get Rates” service operates to provide thecustomer with pricing data regarding one or more particular vehiclerental transactions. The customer computer passes the data values (seecolumn 600) for various data variables of interest (see column 602) tothe reservation booking website in a tagged format as an XML document.For example, in FIG. 68, for the data variable tag PickUpDateTime, thecustomer has provided data indicating a rental vehicle pick-up date ofMay 19, 2003 at the time 1:00 pm, and for the data variable tagReturnDateTime, the customer has provided data indicating a rentalvehicle return data of Jun. 16, 2003 at the time 3 pm. The location codefrom which the customer intends to pick up the rental vehicle (the firstLocationCode variable) is identified as St. Louis Airport (airport codeSTL), and the location code at which the customer intends to return therental vehicle (the second LocationCode variable) is also identified asSt. Louis airport. While this example uses airport codes as the locationcode, it should be understood that the location code used by the parentinvention can be any identifier assigned to any branch location,including non-airport branch locations, or a geographic identifier for aparticular geographic region near where the reservation is desired.

Upon receipt by the website, the website parses the XML document toextract the pertinent data, and maps the data to Java objects that canhanded off to the reservation transaction processor for a determinationof the appropriate pricing rates for such a vehicle rental transaction.After this pricing rate information is determined, the website returnsthe data shown below the “values returned” notation of FIG. 68 to thecustomer computer as an XML document. The core information should matchthe corresponding data provided by the customer. Further, the websitewill return vehicle availability data as to status (available orunavailable) and size.

The number data values for vehicle size relate to the class of therental vehicle, with the numbers 3, 4, 6, 7, 8, 10, 9, 11, and 24corresponding, respectively, to vehicle types economy, compact,intermediate, standard, full size, premium, luxury, minivan, and exotic(e.g., SUV).

Further, the website returns rental rate data values for amount (rate),currency code (e.g., US dollars, British pounds, etc.), a description ofthe rate type (hourly, weekly, surcharge, total charges), quantity (thenumber of vehicles), unit charge, total charge (the final cost), and anyapplicable mileage rules. Further, the website response includes datarelated to the customer's coverage.

The location information for the applicable pricing rate is set forth inthe format, name (branch name), address, postal code, country name,state/province, city name, phone use type, telephone number, andtelephone number area code/city code. Lastly, additional information isreturned by the website, such as any age rules that may apply (“age”)and, possibly notices about available shuttle services (“shtl”), noticesabout available after hours services (“afhr”), or miscellaneousinformation (“misc”). The text for such additional information is alsoidentified.

FIGS. 69( a) and (b) illustrate the format for the preferred “CreateReservation” service request and response. Customers preferably utilizethis service to create a rental vehicle reservation. Relative to the“Get Rates” service, the “Create Reservation” service includes, on thecustomer send side, various pieces of information about the prospectiverenter. However, as would be understood by those of ordinary skill inthe art, not all fields of data would be required to complete areservation transaction, although it is preferred that at least asurname is provided.

Upon receipt of the dat provided by the customer, the website seeks tocreate a reservation in accordance with the data provided. If areservation is not available under the user-provided conditions, anerror message will be returned. However, if possible, a success flag inthe website response is returned to the customer computer together withthe renter information data, reservation core data (including areservation confirmation number), vehicle information, rental rateinformation, priced coverage information, location information, andadditional information as set forth in FIGS. 69( a) and (b).

FIG. 70 illustrates the format for the preferred “Get Reservation”service request and response. This service operates to allow a customerto retrieve data about a pre-existing reservation. The retrievalcriteria, preferably include a confirmation number and renter name asshown, but as would be understood, either criteria could be used. Uponreceipt of this data as part of the “Get Reservation” service request,the website can query the reservation database using the confirmationnumber and/or renter name to obtain the pertinent reservation data. Theinformation described in FIG. 70 is thereafter returned to the customercomputer by the website as an XML document for display on the customer'scomputer.

The preferred “Modify Reservation” service of FIGS. 71( a) and (b) issimilar to the “Create Reservation” service except that the customercomputer provides a confirmation number to the website so that theappropriate reservation can be modified. Further, the returned datavalues include a flag for the “modify status” of “modified” or“unmodified”. It would generally be expected that a customer wouldutilize the “Modify Reservation” service after utilizing the “GetReservation” service. In using the “Modify Reservation” service, thecustomer will modify one or more fields in the reservation core data andrenter information data. Upon receipt of the customer-provided data asan XML message, the website parses the message and determines whether areservation in accordance with the modified data is possible. If not, anerror message is returned, if so, the return message of FIG. 71( b) issent to the customer computer.

FIG. 72 illustrates the preferred format for the “Cancel Reservation”service request and response. This service is similar to the “GetReservation” service from the perspective of the data provided by thecustomer, but is operative to cancel an existing reservation. Uponreceipt of a valid customer cancellation service request, the websitereturns an XML message as shown in FIG. 72( b) wherein the cancel statusis “cancelled” and the cancelled reservation confirmation number isidentified.

The navigational path for the reservation booking website of the parentinvention will now be described. FIG. 9 shows a navigational pathstarting from the home page wherein a zip code has been entered aspartial location information. FIG. 37 illustrates a preferred format forthe home page (H) of the parent invention.

With reference to FIG. 37, page H includes a plurality of fields inwhich the customer can enter reservation data. The four basic types ofreservation data are preferably location information (L), temporalinformation (T), vehicle information (V), customer age (A), andadditional customer information (RI). From the home page, the customercan preferably enter data for L, T, V, and A. Also, it should be notedthat the website can be designed to recognize returning visitors throughthe use of cookies or customer registration, which would eliminate theneed to repetitively gather A and RI information from repeat customers.

Preferably, a customer enters partial L data from the home page thatwill allow the processor 150 to determine a general area (such as ametropolitan area or state) from which the customer is interested inrenting a car. In locational field 302, the customer can enter either azip code, an airport code, or general search text. Business database 206preferably associates each branch location with a plurality of nearbyzip codes to enable zip code searching. Also, any branch locations thatare designated as airport branches (preferably branches near an airport)are associated with the 3 character airport code of the nearby airportto enable airport code searching. If general search text is entered, theservlet will query the business database 206 for all branch locationshaving the entered text anywhere in its address. However, it should beunderstood that other locational search methods may be readilyimplemented (including but not limited to methods such as a drop downmenu listing all of the rental car company's branches—which is not veryefficient for a large rental car company having thousands of branches, apop-up map with geographically-placed hyperlinks, cascaded searches bystate then city then branch, or the like). If a customer wishes thatonly branch locations associated with airports be returned but does notknow the airport code for the airport of interest, a box 326 is providedthat restricts the branches returned from a zip code or general textsearch to only airport branches that satisfy the zip code/text searchcriteria.

Full temporal information is preferably provided in fields 304, 306,308, and 310 which correspond to starting date, starting time, returndate, and return time respectively. It is preferred that default valuesbe used for the temporal information (such as the current date forstarting/end dates and noon for starting/end time) in the event that thecustomer does not enter T data from the home page. In the event errordata is received as a date, the customer will be linked to a “strippeddown” version of page H (SH, see FIG. 57) to re-enter valid temporaldata.

Vehicle information is preferably provided in field 314. A drop downmenu can list available vehicle types (including but not limited totypes such as compact, economy, mid-size, and luxury). Preferably thevehicle type defaults to “all vehicle types” in the event that thecustomer does not enter V data from the home page.

Customer age information is preferably provided in field 322. A dropdown menu can list possible age ranges (including but not limited tobelow 20, 21-24, and 25+). Preferably the age defaults to 25+ in theevent that the customer does not enter A data from the home page.

Upon entering data in any or all of the above-described fields, thecustomer can submit the data (including any default temporal or ageentries that may exist) to the processor 150 by selecting link 324. Thedata entry fields and the “search” link 324 make up a data submitterthrough which the customer can submit at least one data value. It shouldbe noted that the parent invention is not limited to a data submitter asshown in FIG. 37 but encompasses data submission techniques of allkinds, such as a data submitter that is a list of hyperlinks with eachhyperlink corresponding to a different acceptable data value, a datasubmitter that is a drop-down menu of selectable options and acorresponding “select” link, or the like.

Additional preferable features for the home page include (1) variouspromotional links 318 that correspond to any promotions that the rentalcar company is offering (each promotional link 318 being selectable toinitiate a reservation transaction according to the conditions of thepromotion), (2) an “enter corporate account” field 316 through which acustomer can access a corporate account and initiate a reservationtransaction according to the parameters of a profile associated with thecorporate account (preferably the corporate account is accessed byentering a password or the like in field 316), and (3) a “modify anexisting reservation” link 320 which allows a customer to access and/ormodify an existing reservation by entering a reservation confirmationnumber or some other suitable identifier when subsequently prompted. Oneor more message tiles 317 may also be provided on page H (or any pageother than SH). The message tile 317 includes either a link 318 to apromotion or a link to accessing a customer's corporate account.Preferably the message tile 317 is positioned on either end (left orright) of the page, preserving the center of the page for reservationdata interaction.

Returning to FIG. 9, when a customer has selected link 324 afterentering a zip code in field 302, the servlet accesses the businessdatabase to determine the state in which the zip code is located and thebranch(es) associated with that zip code. If the received age data(which may either be the default age data or customer-entered age data)is below the minimum age for renting a vehicle in the zip code's state(21 in most states, 18 in New York), then the servlet links the customerto page APOL3 (see FIG. 61). If not, the servlet queries the database206 to determine whether any returned branches are open at the startingdate and starting time received from the customer (which may be eitherdefault values or customer-entered values). If no such branches areopen, the servlet links the customer to either page CL1 (if a vehicletype has been selected, see FIG. 38( a)), or page CL2 (if no vehicletype has been selected, see FIG. 39). On the displayed CL page, theindicated status for each listed branch will be “closed”.

If open branches do exist, and only one such open branch exists, theservlet proceeds through steps 9.5-9.21. If the customer selected avehicle type from the home page, and the selected vehicle is bothavailable at the branch and available for the customer's age, theservlet links the customer to page BD2 (see FIG. 47) which allows thecustomer to learn more about both the single returned branch (address,etc.) and the vehicle selected (such as price, etc.). If the customerselected a vehicle type from the home page, and the selected vehicle isavailable at the branch but not available for the customer's age, theservlet links the customer to page APOL3 (see FIG. 62) which informs thecustomer of the vehicle's unavailability based on an age restriction. Ifthe customer selected a vehicle type from the home page, and theselected vehicle is not available at the branch but other cars areavailable at the branch, the servlet links the customer to page BD1 (seeFIG. 46) or BD4 (see FIG. 49) depending upon whether the branch isdesignated an airport branch. BD1 and BD4 let the customer know of theother vehicles that can be selected at the branch while also informingthe customer about the single returned branch. Because airport branchesoften have extended operating hours, after closing vehicle drop-offs,and shuttle services, airport branches are given special attention inthe parent invention (although this need not be the case). If thecustomer selected a vehicle type from the home page, and the selectedvehicle is not available at the branch, nor are any vehicles availableat the branch, the servlet links the customer to page APOL1 (see FIG.59) or APOL2 (see FIG. 60) depending upon whether the branch is anairport branch. APOL1 will provide the customer with a link outside thesummary section (to be described below) that allows the customer tochange branch locations. APOL2 preferably does not provide such a linkoutside the summary section. Both APOL1 and APOL2 inform the customerthat the branch has no vehicles available at the selected starting time.If the customer did not select a vehicle type from the home page, andthe selected vehicle is not available at the branch, nor are anyvehicles available at the branch, the servlet links the customer to pageAPOL1 (see FIG. 59). If the customer has not selected a vehicle typefrom the home page, and the selected vehicle is not available at thebranch but other cars are available at the branch, the servlet links thecustomer to page BD1 (see FIG. 46) or BD4 (see FIG. 49) depending uponwhether the branch is designated an airport branch, which lets thecustomer know of the other vehicles that can be selected at the branch.

If more than one open branch is returned from the database query at step9.4, the next action needed from the customer is a selection of one ofthe plurality of branch locations meeting the zip code search criterion(steps 9.22-9.24). Depending upon whether the customer entered a vehicletype, the servlet links the customer to either page CL1 (see FIG. 38) orCL2 (see FIG. 39) which list the locations available for selection basedon the submitted data.

FIG. 10 illustrates essentially the same process as FIG. 9 with theexception that the customer entered search text in field 302 rather thana zip code (which affects the “choose location” pages now denoted asbeing either CL3 and CL4, see FIGS. 40-41). Likewise, FIG. 11illustrates essentially the same process as FIGS. 9 and 10 with theexception that the customer has either entered an airport code in field302 or entered either a zip code or search text in field 302 afterchecking box 326. Because it is known that only airport branches arereturned from the database query, the process of FIG. 11 (unlike thoseof FIGS. 9 and 10) does not need any decision-making based on whether aparticular branch is flagged as an airport branch.

FIG. 12 illustrates a navigational flow from the home page where thecustomer enters any combination of age, vehicle, and/or time data—but nolocational data is entered in field 302. In such cases, the servletlinks the customer to page SH (see FIG. 57) which is a stripped downversion of the home page. FIG. 13 shows the navigational flow from pageSH, and is self-explanatory. Data entries other than locational dataresults in the customer being looped back to page SH.

FIGS. 14 and 15 illustrate the navigational flow from the “chooselocation” pages CL1-CL4. An exemplary screenshot of CL1 is shown in FIG.38( a). Referring to FIG. 38( a), CL1 lists a plurality of branchlocations 332 that meet the zip code criterion provided by the customer.Because CL1 is reached when the vehicle type for the reservation isknown, each branch listing 332 also lists that branch's status as to theavailability of the selected car (see vehicle availability status column336). Each branch listing 332 also lists that branch's distance from aselected point in the zip code provided by the customer (see branchdistance from zip code column 334). Preferably, CL1 lists not only thebranches that are acceptable for selection as determined from thecurrent reservation data (i.e., open branches having the selectedvehicle available at the selected time) but also branches that areunacceptable for selection based on current reservation data (i.e., thebranch listings denoted as “closed” or “sold out”). While such branchesare not acceptable for selection via link 338, the customer may desireto change other reservation data to make a particular locationacceptable. For example, by selecting the link 342, a customer will belinked to a branch details page allowing the customer to possibly changereserve time (steps 14.14-14.16).

For each branch listing 332 where the selected vehicle is available, a“select” link 338 is provided nearby that allows, upon selectionthereof, the customer to select the branch to which the “select” linkcorresponds. No “select” links are provided for branches where eitherthe selected vehicle is unavailable or the branch is closed during theselected start time. Each branch listing also includes a “view branchdetails” link 342 that, upon selection, links the customer to a page (aBD page) that provides more details as to the pertinent data for thebranch (i.e. hours of operation, rental policies, shuttle service (ifavailable), etc.) and if a vehicle has not been selected also presentsthe customer with a listing of available vehicles. Furthermore, a “next5/prev 5” link 340 is also provided (when the number of branch listingsexceeds a predetermined number, which is preferably however many branchlistings comfortably fit on the page). Upon selection of link 340, theCL1 page is redisplayed with the next 5 or previous 5 branch listings.

Another feature of the parent invention that can be seen on the CL1 pageis summary section 330. Summary section 330 provides the customer with arunning summary of reservation data submitted to processor 150. Summarysection 330 preferably includes a listing for L stage data 346 which canbe seen in FIG. 38 as not yet existing, T stage data 348 which is thestart date/time and end date/time provided by the customer, V stage data350 which is the vehicle type data provided by the customer, A stagedata 352 which is the age data provided by the customer, and RI stagedata 354 which is the renter information provided by the customer. Thesummary section 330 also includes, for each reservation data type forwhich a complete data value has been received, a nearby (preferablyadjacent as shown) “editing” link 360. “Editing” link 360 is selectableto initiate a revision to the data with which the link is associated.The “editing” link provides the parent invention with a uniqueuser-friendliness and flexibility that allows customers to easily reviseany errors that may have been made when entering data or quicklyimplement changes of mind. In the example of FIG. 38, it can be seenthat only the T stage data 348 has been provided by the customer, and assuch, an “editing” link 360 is situated adjacent thereto.

While it is preferred that the summary 330 include a separate edit linkfor each listed data value, this need not be the case. By providingseparate edit links for each listed data value, the user-friendliness ofthe summary section 330 is improved because the customer can initiallydetermine how to best initiate a data value revision. However, lesspreferred edit link implementations can be used, such as a single editlink within the summary section 330 that is selectable to initiate arevision for any of the listed data values, or the like.

Furthermore, summary section 330 preferably includes a progress marker344 which notifies customers of how far along they are in thereservation booking process. In the example of FIG. 38( a), progressmarker 344 notifies the customer that the process is 20% complete(preferably the stages considered by the progress marker are T, V, L,RI, and a verification stage). However, as would be apparent to those ofordinary skill in the art, more or fewer stages could be considered incalculating the percentage complete for the progress marker. As can beseen in connection with the other screenshots shown in the figures, thesummary section 330 provides a useful tool through which customers canoptimize the reservation booking process.

FIG. 40 illustrates CL3 which closely matches CL1, except column 334 isnot included (because the customer has not provided a zip code). FIG. 41also shows an example of another hyperlink that may appear on either CL1or CL3—the “check other vehicles” link 360. Whenever the selectedvehicle is unavailable at one of the branch listings 332, a “check othervehicles” link 360 is preferably provided as an action item for thebranch that is selectable to both select the corresponding branchlocation and initiate a “change vehicle” edit.

Also, FIG. 38( b) illustrates a link 550 that can be provided on any ofthe CL pages (see FIGS. 38( a), 39, 40, and 41) for restricting the listof branch locations in an area to only branch locations designated asairport branches. Upon user selection of the “show airport locations”link 550, the page of FIG. 64 is presented the user. As can be seen inFIG. 64, the branch locations available for selection have beenrestricted to only the airport locations meeting the original searchcriteria. It is preferred that the page of FIG. 64 also include a “showall locations” link 552 that returns the user to the full range ofbranch locations that are available for selection (as presented to theuser prior to the user's selection of link 550). Because many rentalvehicle customers are interested in renting vehicles at airport branchlocations as those locations are most convenient for airport travelers,this “show airport locations” link 550 provides a valuable tool inattracting and retaining air travelers to the rental vehicle website asa result of the increased user-friendliness. Further still, this featureof the invention is particularly valuable for a reservation bookingentity that has thousands of branch locations (with each city with amajor airport having numerous branch location) because it allowscustomers who arrive in a city via air to quickly identify theappropriate branch location for a reservation (the airport branchlocation) without the need to sift through several other branchlocations that are located in the city. It is worth noting that a branchlocation can encompass any individual rental office or facility of arental company, a rental franchise location, a rental retail locations,satellite location, or any other location at which a rental vehicle maybe procured. An airport branch location designates a branch locationnear an airport (or often on airport grounds) that is designated for orprimarily dedicated to servicing customers who arrive from the nearbyairport.

FIG. 14 illustrates the navigational path starting from either CL1 orCL3. If the customer selects one of the listed branches, the servletfirst checks whether the selected branch is flagged as an airportbranch. If so, the servlet checks whether the return time for thereservation is after the branch's closing time. If the return time ispost-closing, the customer is linked to an “after hours” (AH) page (seeFIG. 58) which provides the customer with the option of either acceptingthe selected branch's after hours return policy (continue to step 14.6)or initiating a change to the reservation time (link to page ChT2,described in more detail below). At step 14.6, a VD1 page (see FIG. 44)is displayed which notifies the customer of important vehicleinformation such as base rate and total rental cost.

If step 14.2 determines that the selected branch is not an airportbranch, then the servlet proceeds through steps 14.7-14.11. In the eventthe selected branch offers an after hours return policy, the steps14.8-14.11 are performed (which essentially mirror 14.3-14.6 exceptnon-airport page versions are displayed). If there is no after hourspolicy at the selected branch and the return time is after closing,steps 14.11-14.13 are followed.

Another selection possibility from CL1 or CL3 is the selection of a“view branch details” link 342. If a link 342 is selected, then thecustomer is linked to a “branch details” page (either BD2 or BD3depending on whether the selected branch is an airport branch—see FIGS.47-48). The BD pages provide detailed information about the branchcorresponding thereto.

Other selection possibilities from CL1 or CL3 are derived from the“editing” links 360 in the summary section 330. Because it is preferredthat default values be used for T data and A data in the absence ofmodification thereof by the customer, summary sections 330 will alwaysinclude “editing” links 360 corresponding to changing the reservation'stemporal data and changing the customer's age. Selection of those“editing” links will link the customer to pages SH (see FIG. 57) and ChA(see FIG. 56) respectively. Also, because CL1 and CL3 will always bereached when a vehicle type has been selected, the “editing” link 360corresponding to V stage data will also be present and selectable tolink the customer to a “choose vehicle” page (CV1) (see FIG. 42).Furthermore, in the event that the renter information is known (theconditionality of the “change RI” path is indicated by the dashedlines), an “editing” link 360 corresponding thereto will be present inthe summary section 330 and selectable to link the customer to a changerenter information page (RI)—see FIGS. 50( a)-(b). Renter information(RI) (see FIG. 50 for an example of information desired) can be obtainedeither through data entry from page RI or through a customer profilelearned either from customer registration/log-in or cookie recognition.Further, any customer profiles used with the parent invention may alsoinclude parameters such as “preferred vehicle type”, “preferred branchlocation” or the like to further expedite subsequent reservationtransactions.

FIG. 15 illustrates the navigational path starting from CL2 or CL4. Anexemplary screenshot for CL2 is shown in FIG. 39, and an exemplaryscreenshot for CL4 is shown in FIG. 41. Like CL1, CL2 includes column334 because CL2 is reached when the customer provides a zip code infield 302 of page H. Also, because no vehicle information is known, alocation status column 362 is provided that identifies whether anyvehicles are available at the listed branches and whether the branch isopen for business at the selected start date/time. Also of note is theairplane icon 364 that appears beside any branch listings 332 that areflagged as airport branches to notify customers of which branches areairport branches.

CL4, shown in FIG. 41, is highly similar to CL2 except column 334(distance of branch from zip code) is not shown because no zip code wasentered by the customer when reaching CL4. Like CL2, CL4 includes abranch status column 362.

FIG. 15 illustrates a navigational path for the parent inventionstarting from either page CL2 or CL4. Steps 15.2-15.13 of FIG. 15parallel steps 14.2-14.13 of FIG. 14, with the exception that CV pagesare reached at steps 15.6 and 15.11 instead of VD1 pages (as in FIG.14). Furthermore, because no vehicle is selected, steps 15.15-15.17 linkthe customer to a BD page that allows the customer to make vehicleselections therefrom.

FIGS. 16 and 17 illustrate navigational paths for the parent inventionstarting from the CV pages, and are readily understood upon reading theCV page information below. Exemplary screenshots for CV1 and CV2 areshown in FIGS. 42 and 43 respectively—the only difference being that CV1corresponds to a reservation where the selected branch is not an airportbranch and CV2 corresponds to a reservation where the selected branch isan airport branch. Both CV1 and CV2 include a vehicle inventory list forthe selected branch. Both acceptable vehicle types (those with a selectlink 376) and unacceptable vehicle types (those without a select link376) are preferably listed.

Each vehicle listing 370 identifies the vehicle type (economy, compact,etc.), a link 372 to “view vehicle details”, a description of the makesand models for the class, a price quote, and when the vehicle isavailable, a “select” link 376. The price quote preferably includes botha daily rate for the vehicle and a total price listing reflective of thedaily rate times the number of reservation days (known from T data) plusany surcharges, taxes, etc. By displaying both the daily rate and totalprice, the customer is made more fully aware of price issues for thereservation. With this feature of the parent invention, when thecustomer desires a particular vehicle, he/she can learn if any otherbranch locations (some of which may be sufficiently nearby) offer thedesired vehicle. If a listed vehicle is unavailable, a link 378 isprovided which, upon selection, allows the customer to both (1) selectthe vehicle and (2) link to a choose location page (CL1 or CL3). CV1 andCV2 also both include summary section 330.

FIGS. 18 and 19 illustrate the navigational paths starting from thepages VD1 and VD2 respectively. FIGS. 44 and 45 illustrate examples of“vehicle details” screenshots for VD1 and VD2 respectively. Referring toFIG. 44, VD1 includes information listing 390 that contains detailedinformation about the selected vehicle. This detailed informationpreferably includes a make/model description, a listing of vehiclefeatures (such as A/C, stereo, engine, number of doors, etc.), a pricequote (preferably both a daily rate and a total cost), etc. Links 392and 394 allow the customer to link to a “vehicle details” page for thenext smaller or next larger vehicle classes respectively. The “all” link360 between links 392 and 394 corresponds to a “change vehicle” link.The “select” link 398 is provided for customers who, upon reviewing thedetails shown in listing 390, wish to select the shown vehicle. VD1 alsoincludes a summary section 330.

VD2 includes a listing 390 of vehicle details for a vehicle that isunavailable for selection. VD2 is typically reached when link 392 or 396of VD1 is selected and calls up a vehicle class that is unavailable. VD2also preferably includes summary section 330.

FIGS. 20-23 illustrate navigational paths starting from various “branchdetails” (BD) pages and are readily understood upon reading the BD pageinformation below. An exemplary BD1 is shown in FIG. 46. BD1 showspertinent branch information for a selected non-airport branch when novehicle has been selected. Listing 400 includes pertinent branchinformation such as operating hours and address. Because no vehicle hasyet been selected, BD1 also includes a vehicle menu 402 that lists thevehicle inventory for the selected branch. Menu 402 is similar to aminiature “choose vehicle” page. Each vehicle listing includes a pricingcolumn 380 and a “selection” column that includes links 376. The“select” links 376 are selectable to submit the vehicle correspondingthereto as the V data for the reservation. Each entry in the pricingcolumn preferably includes both the daily rate and the total cost asexplained above. BD1 also includes a summary section 330. BD4, shown inFIG. 49, closely corresponds to BD1, with the exception that theselected branch is an airport branch, and as such, the information inlisting 400 is preferably slightly different.

An exemplary BD2 screenshot is shown in FIG. 47. BD2 is reached when avehicle has already been selected. As such, BD2 includes a “selectedvehicle information” listing 408 which is similar to a miniature VD1page. Listing 408 includes pertinent information about the selectedvehicle, a link 360 that is selectable to link to a CV page, and a link410 selectable to continue the process with the selected vehicle. Thepertinent information in listing 408 preferably includes both a dailyrate and a total cost as explained above. BD2 also includes a summarysection 330. BD3, shown in FIG. 48, closely corresponds to BD2 with theexception that the selected branch is an airport branch, and as such,the information in listing 400 is slightly different.

FIG. 24 illustrates a preferable navigational path starting from the“enter renter information” page (RI) and is readily understood uponreading the RI page information below. An exemplary RI page is shown inFIGS. 50( a) and 50(b). The RI page preferably includes a field 420 inwhich the renter's name can be entered, a field 422 for the renter'sphone number, a field 424 for the renter's e-mail address, a field 426for the renter's credit card type, and a plurality of fields 430 foradditional information that is generally needed from the customer by arental car company employee working at the counter of the branchlocation when the customer actually arrives to pick up the rental car. A“continue” link 428 submits any entered data to the processor 150. Nofields in RI need to be required, however, it is preferred that thename, phone number, and credit card type fields be flagged as requiredfields. The RI page also includes a summary section 330.

FIGS. 25 and 26 illustrate preferred navigational paths for the parentinvention starting from a “verify” (V) page and are readily understoodupon reading the V page information below. FIGS. 51 and 52 are exemplaryscreenshots for an non-airport version (V1) and an airport version (V2)respectively of the “verify” page. Both V1 and V2 include a listing 440of pertinent information for the rental, such as important terms andconditions, after hours information, and a total cost estimate (theinformation in listing 440 may include additional airport-related datasuch as shuttle availability information). Summary section 330 isincluded in V1 and V2 to identify the data values for the differentreservation data types 346-354 that have been submitted to the processor150. Should the customer wish to revise any of the data entered for thereservation transaction, the “editing” links 360 are available. Link 442is a “booking” link that submits the reservation to the processor 150for final booking. Link 444 is a “cancel” link that cancels thereservation, and link 446 is an “upgrade” link that is selectable tolink the customer to a “vehicle details” page for the vehicle of thenext larger vehicle class.

In the event the customer decides that all information on the “verify”page is correct and the reservation is ready for booking, afterselection of the “booking” link 442, the customer is linked to a“confirmation” page. FIG. 27 illustrates the preferred navigational pathfor the present invention starting from the “confirmation” page (Conf).FIG. 53 illustrates an exemplary screenshot for Conf. The Conf pageincludes confirmation information 450, the confirmation information 450,and a confirmation number 498. A “print” link 452 is provided to allowthe customer to print out the reservation confirmation number and datavalues. A “create another similar reservation” link 454 is provided toallow the customer to repetitively make new reservations using thecurrent reservation data as the starting point (upon selection of link454, the customer is linked to a “verify” page wherein the reservationdata matches the current reservation data, and wherein the customer isprovided with the ability to, if necessary, modify the reservation datawhen making the new reservation). Additional preferable links on theConf page include a “speed your time at the counter” link 456 thatappears if the customer did not fully fill out fields 430 in the RIpage. Link 456 is selectable to return the customer to page RI or ashortened version thereof that includes only the fields 430. Also, theConf. Page preferably includes a “modify/cancel” link that isself-explanatory.

The preferred navigational paths starting from the “change time” pagesare shown in FIGS. 28-29 and are readily understood upon reading the“change time” page information below. An exemplary ChT1 page is shown inFIG. 54. ChT1 is reached when a customer has opted to change thereservation time after already selecting a non-airport branch location.Listing 470 preferably provides business hours information for theselected branch and possibly additional information such as an address.Fields 304-310 are provided to update the reservation time. Link 472 isselectable to submit the updated reservation time. “Show more locations”link 360 is analogous to a “change location” edit link 360 shown insummary section 330. An exemplary ChT2 page is shown in FIG. 55. ChT2 ishighly similar to ChT1 except ChT2 is reached when the selected branchis an airport branch. Also, ChT2 preferably does not include a “showmore locations” link 360.

FIG. 30 illustrates the preferred navigational path for the parentinvention starting from the “change age” page (ChA), an example of whichis shown in FIG. 56. Referring to FIG. 56, from field 480 of the ChApage, the customer can change the age value for thereservation—preferably to one of three groups 25+ (unrestricted), 21-24(some vehicle restrictions exist), and 18-20 (only allowed to rent avehicle in New York). The ChA page also preferably includes the summarysection 330. As shown in FIG. 30, the navigational path from the ChApage requires additional decision-making based on age (given the new agedata, is the customer eligible to rent any vehicles? the selectedvehicle?).

FIG. 58 illustrates a preferred screenshot for the “after hours” pagereached when the selected return time for an airport branch is afterclosing. The AH page includes a listing 490 that notifies the customerof the after hours return rules. The AH page preferably further includesa “change time” link 360 that is selectable to link to a ChT page, and a“continue” link 492 that is selectable to indicate that the customeraccepts the after hours conditions. Once again, the AH page includes asummary section 330.

FIGS. 59-61 are exemplary screen shots for apology conditions. APOL1,shown in FIG. 59, includes apology field 494 that notifies the customerthat all vehicles at the selected location are sold out. Outside of thesummary section 330, a “try new dates” link 360 is provided along with a“search for a new location” link 360. Also, a “return home” link 460 isprovided. “Try new dates” link 360 links the customer to a ChT page,“search for a new location” link 360 links the customer to a CL page,and link 460 is selectable to link the customer to the home page (H).APOL1 also includes summary section 330.

APOL2, shown in FIG. 60, closely tracks APOL1 except a “search for a newlocation” link 360 is not provided (outside of the edit link 360corresponding to a location change in summary section 330).

Also, APOL3, shown in FIG. 61, listing 496 notifies the customer thatage restricts him/her from vehicle rental. Link 460 is a “return home”link.

FIG. 62 illustrates an exemplary “reservation cancellation” page(Cancel) that includes “cancel” link 498, “don't cancel” link 500, andsummary section 330.

From the home page of FIG. 37 (as well as most other pages), the parentinvention provides a branch location search tool via the “locations”link 520 of FIG. 37. User selection of link 520 causes display of thepage shown by FIG. 65 on the user's computer. From the page of FIG. 65,a user can browse branch locations until finding the appropriate one forreservation. With reference to FIG. 65, field 522 is provided for userentry of a postal code or city name. Field 524 is provided, preferablyas a dropdown menu, so that the user can identify the country in which areservation is sought. The data provided in these fields serves assearch criteria that the system uses to query the database and retrieveall branch locations meeting that user-provided criteria.

Once the database has returned branch location data meeting thiscriteria, the page of FIG. 66 is presented to the user. FIG. 66 listseach branch location's name 526 and city/state 528 meeting the searchcriteria. Each entry also has a corresponding “details and map” link 530that the user can select to learn more about the branch locationassociated therewith. Further, the “new search” link 532 is preferablyprovided to take the user back to the page of FIG. 65 upon selection.

FIG. 67 illustrates the page presented to the user upon selection of a“details and map” link 530. The page of FIG. 67 presents additionalinformation about the pertinent branch location, including name andaddress 534 and hours of operations 536. “Map” link 540 is selectable bythe user to display a road map around the branch's geographic location.Also, it is preferred that a “search again” link 532 be present toprovide the same functionality as the “new search” link of FIG. 66.Lastly, the page of FIG. 67 provides a “reservation” link 538 thatallows the user to select the pertinent branch location and directlyjump into the reservation process using the pertinent branch location asthe selected branch location. The user is preferably entered into thenavigational path as if the user has selected the branch location 534and any other reservation data that the user may have previouslyprovided. Thus, the preferred embodiment of the parent inventionprovides users with yet another flexible technique for identifying abranch location of interest and beginning the reservation process.

Another aspect of the parent invention is the concept of “deep-linking”customers into a stage of the reservation booking process commensuratewith the conditions of a promotion they have selected or a corporateaccount they are using. When a customer selects a promotional link (link318 shown in some of the screenshots, including H and Conf), it istypical that the promotion has one or more conditions associatedtherewith. For example, a rental car company may offer a promotion for areduced rental price for a particular type of vehicle during a specifiedtime period. To promote the promotion, the rental car company mayprovide hyperlinks on other websites through advertising or the like, ormay include promotional links on its own website to attract customers.

When a customer selects such a promotional link to initiate areservation transaction, it is preferable that the user begin thereservation transaction with the reservation data corresponding topromotional conditions set equal to those conditions, to thereby avoidunnecessarily requiring the customer to enter such data himself/herselfor creating a situation where the customer may accidentally enter datathat violates the conditions of the promotion. For example, if apromotion has a condition that the type of vehicle must be “standard”,it is preferable that the customer, upon selection of a linkcorresponding to that promotion, be linked into the reservation bookingprocess such that the vehicle type is automatically set to “standard”.FIG. 31 illustrates this “deep-linking” concept. In one example, apromotion has one condition: the vehicle type must be “economy”. Uponselection of an icon or link associated with that promotion, thecustomer is preferably linked to a state where V has been automaticallyset to “economy”, and the remaining options are to choose a time andlocation. In another example, a promotion has two conditions: thevehicle type must be “luxury” and the duration of the reservation muststart on Jul. 5, 2002 and end of Jul. 6, 2002. Upon selection of an iconor link associated with that promotion, the customer is preferablylinked to a state where V has been automatically set to “luxury” and Thas been automatically set to “Jul. 5, 2002 through Jul. 6, 2002”, andthe only remaining option to choose is location.

Furthermore, as is apparent from the preceding navigational paths andscreenshots, the present invention provides customers with unparalleledflexibility in entering the data necessary to book a reservation,including the ability to possibly change one or more promotionalconditions. To avoid situations where a customer unknowingly modifies adata value such that a promotional condition is violated, the process ofFIG. 32 preferably runs after each data submission when the customer ison a promotional path. If a promotional icon has been selected, theservlet checks whether any of the data provided by the customer violatesany of the promotion's conditions (step 32.2). If no violation is found,any remaining reservation data corresponding to a promotion condition isautomatically set in accordance with the promotion condition (step 32.4)and the customer is deep-linked into the website of the parent inventionto a page that is appropriate given the reservation's current datastatus.

If a violation is found, the customer is linked to a “notice” page (step32.3). The “notice” page informs the customer which data value violatesthe conditions of the promotion and why. FIG. 33 illustrates thenotification process wherein the customer is given an option to revise.The notice page shown in FIG. 63( a) includes a notification 401 that apromotional condition has been violated, including an identification ofwhich reservation data violates the condition. Preferably, notification401 also identifies what the promotion condition is. A “change” link 403is provided to allow the customer to revise the out-of-promotion data toin-promotion data and a “continue” link 405 which allows the customer tocontinue the reservation outside the promotion condition.

Other examples of potential promotional conditions that the servletshould be designed to handle are conditions that are ranges ofacceptable data values, such as a promotion that may be taken advantageof any day during the month of August. Although the automatic settingaspect of deep-linking would be inapplicable to such range-basedconditions because more specific time information is needed from thecustomer, the process of FIGS. 32 and 33 should still run to identifywhether the customer has entered time data not in the condition's range.

FIGS. 34-36 illustrate the same “deep-linking” concept as applied tocorporate accounts. Many businesses or groups of people set up so-called“corporate accounts” wherein a profile is established for thebusiness/group. Data stored in a profile may be the types of vehicleseligible to be rented within the parameters of the corporate account,renters whose age and personal information are remembered between visitsto the website, etc. The profile data may also include graphicalenvironment settings, such as “co-branding” of the website pages so thata business logo, trademark, or the like of a business partner with acorporate account is displayed on the web pages presented to a user.With reference to FIG. 37, a business partner's logo/trademark can bemade to appear in field 317 as part of this co-branding process.“Co-branding” provides users with comfort in knowing that they have notstrayed off the corporate account path for the reservation transactionas a result of the reassuring sight of the familiar companylogo/trademark and also provides business partners with improvedvisibility for their name and logo.

Further, the profile data may include customer-preferred settings forfeatures such as e-mail notifications (the addresses to whichconfirmation/notice e-mails are sent, whether promotional offer e-mailswill be sent or withheld, etc.).

When a customer accesses the website of the parent invention andindicates a desire to use his/her applicable corporate account (seefield 316 of page H), the “deep-linking” concept of FIG. 34 can be used.Also, the steps shown in FIGS. 35 and 36 parallel those of FIGS. 32 and33 for promotional “deep-linking”. FIG. 63( b) illustrates a page forwhen reservation data involves a corporate account parameter. In thisexample, it can be seen that “full size” vehicles are unavailable forreservation through the applicable corporate account because they are“not in [the] agreement”. Optionally, the notice page of FIG. 63( b)also includes links 403 and 405 as shown in FIG. 63( a) (not shown).

Another technique for providing corporate account deep-link access asshown in FIG. 34 is to provide business partners having a corporateaccount with a uniform resource locator (URL) that the websiterecognizes as being associated with a particular business partner andwhose invocation results in gaining deep-link access to the website inaccordance with that business partner's corporate account parameters.The URL is preferably provided to the business partner via e-mail,however any other known mode of communicating data can be used. Also,while it is generally expected that an employee of the business partnerwould incorporate a URL received via e-mail on, for example, thebusiness partner's intranet site, it is also possible that an employeeof the reservation booking entity would be asked to install the URLdirectly on the business partner's intranet site himself/herself.

Different fields of the URL can identify different pieces of informationthat the website may use to find the appropriate page at which to dropthe customer into the reservation website. For example, the URL caninclude a field for a corporate or customer account. The URL may includea field that identifies a preferred branch location from which to rent avehicle. Essentially, the URL may include any piece of information thatis useful for deep-linking the customer into the reservation process.Further, it is worth noting that the URL can include a combination ofdata values for various pieces of reservation information for ahighly-focused deep-link. For example, a deep-link URL that is providedto a repeat user can be as follows:

-   http://www.enterprise.com/car_rental/deeplinkmap.do?BID=X&cust=12345&gpbr=abc    wherein the URL includes a “BID” field for identifying the    parameters that can be expected in subsequent fields of the URL and    how those parameters should be processed, a “cust” field for    identifying an account number, and a “gpbr” for identifying a    preferred branch location. Using the data values of X, 12345, and    abc for these parameters, the customer who invokes this URL can be    deep-linked into the reservation process at a page wherein the    branch location has already been entered (the location that    corresponds to the code “abc”) and wherein any rates that are    available to account number 12345 are made available.

This URL can be placed on the business partner's computer system,preferably the business partner's intranet site or a portion of thebusiness partner's internet site having restricted access (so that thebusiness partner may exert some control over who gains access to thecorporate account). However, it should be understood that such URL linkscan also be placed on general access Internet websites. Also, ratherthan invoking the URL from a link placed on the business partner'sintranet site, an employee of the business partner may also invoke theURL from a link in an e-mail sent directly to that person by thereservation booking entity. Such links are valuable because they providesingle click deep-link access to the reservation booking website.However, other less time efficient means of invoking the URL can stillbe used, such as typing the URL into a web browser. Therefore, from theintranet site or the like of a business partner, a user can gain directdeep-link access to the reservation website by clicking on a hyperlinkthat deep-links that user to the reservation website. Such a hyperlinkprovides a large degree of user-friendliness in that the user isalleviated of the need to remember a corporate account number in a fieldsuch as field 316 of FIG. 37.

Also, repeat users other than members of business partners (e.g.,ordinary customers who wish to reserve a rental vehicle) can takeadvantage of the deep-linking aspect of the preferred embodiment of theparent invention. Accounts, or profiles, can be created for suchcustomers and stored in a database (e.g., database 208 of FIG. 6).

The customer account preferably includes a plurality of customerparameters that relate to personal information about the customer andpreferred reservation settings. The personal information would includeinformation such as name, address, telephone number, e-mail, etc. Thispersonal information can include any piece of information shown on theRI page of FIGS. 50( a) and (b), and may include other types of personalinformation. Examples of preferred reservation settings that can beincluded in the customer account include a “favorite” branch location(e.g., the branch location at which the customer generally prefers torent vehicles), a “favorite” vehicle type, a “favorite” airport (e.g.,the airport at which the customer will most often need rental vehicletransportation, whether and what type of insurance coverage is desired,and may also include second, third, etc. “favorites” for these criteria.Further, the customer account parameters can define the type ofmarketing information that the customer receives (e.g., whether e-mailnotices of promotional offers are provided to the customer, etc.)

The customer account can obtain this data through either acustomer-interactive page presented to the customer, wherein thecustomer is prompted for such information and, after providing therequested data, submits the parameter information to the database forstorage. Alternatively, this information can be obtained in an automatedfashion by creating accounts for new customers as they bookreservations. The customer account parameters may then change over timeas the account keeps track of the customer's preferences forsubsequently booked reservations. Further still, at the verify stage fora reservation, a checkbox or the like can be provided on the verify pagethat upon selection by the customer causes an account to be created thatstores the data provided by the customer in booking the reservation asthe account parameters.

Once an account has been created for the customer, subsequent visits bythe customer to the reservation booking website can take advantage ofdeep-linking. Through either recognition of a cookie that has beenplaced on the customer's computer or verification of a customer accountnumber provided by the customer (a customer having an account can beprovided with a customer number that identifies his/her account), acustomer can be deep-linked into the reservation booking process afterthe website has retrieved one or more of that customer's accountparameters. The page at which the customer is deep-linked into thewebsite may be a page at which the customer has already “selected” (byvirtue of the customer account-based deep-link), for example, aparticular branch location or vehicle type. Further, the customer ispreferably alleviated of the need to re-submit personal renterinformation because that information can be pre-loaded via thedeep-link. In a most preferred instance of customer account-baseddeep-linking, the deep-link takes advantage of all personal informationin the customer account that is necessary for booking a reservation, a“favorite” branch location in the customer account, and a “favorite”vehicle type in the customer account. With such a deep-link, the onlydata that a customer would need to provide to complete the reservationprocess is a pickup and return date and time. Further still, when acustomer has provided a list of first, second, third, and so on“favorite” branch locations or vehicle types, the page to which thecustomer is deep-linked can present a dropdown menu of these preferredbranch locations or vehicle types to the customer for appropriateselection thereof.

Further still, customer account-based deep-linking can be used inconjunction with promotional deep-linking such that when a customerselects a promotional link (that may be provided via e-mail or posted ona page as a hyperlink), the resultant deep-link combines any promotionalsettings with any stored customer account parameters.

Further still, with the parent invention, travel agents can be providedwith an identifier, preferably their Airline Reporting Corporation (ARC)number, for use when accessing the reservation website. Similarly, thisARC number can be included in a URL provided to the travel agent fordirect deep-link access to the website. These identifiers can then bestored in a database. The identifiers can be associated with each travelagent individually or with the travel agent by way of a travel agency orsimilar such organization. Each reservation transaction completed by thetravel agent will then be associated with that particular travel agent(or travel agent organization) via the travel agent identifier. Thisassociation will be a valuable tool for determining any commissions thatthe travel agent/agency may be entitled to. Further, travel agents andtravel agencies can set up corporate accounts as described above toenable deep-linking access to the reservation website in accordance withany preferred settings and features that the travel agent/agency maywork out with the entity controlling the reservation website.

Yet another aspect of the parent invention lies in the ability to customdefine promotions and corporate accounts. As shown in FIG. 73, throughan interface 700, an account or promotion administrator can control aplurality of settings for the pages and rules of a promotion orcorporate account. These settings are then stored with the appropriateaccount in the database 208 for subsequent retrieval and processing.

Through the interface 700, it is preferred that the administrator beable to control nearly all aspects of the pages that a customer seesupon initiating a reservation transaction via a corporate or customeraccount or promotion. For example, the parameters set through GUI 700can control whether a marketing tile (see reference numeral 317 in FIG.37) is displayed on the user-interactive reservation pages. Similarly,the navigation bar (see reference number 706 in FIG. 37) that is presentin virtually all pages of the reservation process can be eliminated (itis expected that many business partners will prefer that the navigationbar be removed because its invocation will often cause users to departfrom the scope of the business partner's account—such as entering into acar sales realm of a website). Further still, on a CV page, the list ofavailable vehicle types for selection can be limited to one or moredifferent classes.

In the example of FIG. 73, which includes an exploded view of a GUI 700that can be presented to the administrator, it can be seen that theadministrator has control over several parameters, including (1) whetherthe navigation bar 706 is turned on or off, (2) the countries in whichthe corporate account/customer account/promotion is applicable, (3)whether the corporate account/customer account/promotion is limited to aparticular market, (4) and if limited to a particular market, the nameof the market (via a dropdown menu), (5) whether the age selectionfeatures of the pages should be turned on or off, (6) what vehicleclasses are available through the corporate account/customeraccount/promotion, (7) the rate reduction applicable to the corporateaccount/customer account/promotion, (8) whether co-branding should bedisplayed on the pages in connection with the corporate account/customeraccount/promotion, and (9) whether the damage waiver should be turned onor off for the corporate account/customer account/promotion. Moresettings can be controlled upon selection of a “more options . . . ”link 704. To save the settings to the database 208, the “save toaccount” link 704 is available.

It is preferred that an employee of the reservation booking entity serveas the administrator. However, it should be appreciated that theadministrator can also be an employee of the business partner. Through anetwork connection with the database 208, the GUI 700 can be displayedon the computer of a business partner employee, and the accountparameter data can be appropriately stored in the database.

While the parent and present inventions have been described above inrelation to their preferred embodiments, various modifications may bemade thereto that still fall within the inventions' scope, as would berecognized by those of ordinary skill in the art. Such modifications tothe inventions will be recognizable upon review of the teachings herein.As such, the full scope of the parent and present inventions is to bedefined solely by the appended claims and their legal equivalents.

1. A method of processing a rental vehicle reservation transactionbetween a customer computer and a rental vehicle reservation-makingentity via a rental vehicle reservation booking server accessed by acustomer computer over a computer network, the method comprising:receiving reservation data from the customer computer; booking areservation transaction in accordance with the received reservationdata; and communicating data to the customer computer for displaythereon after the reservation transaction has been booked, wherein thecommunicated data includes a link that is selectable by the customer tocreate a new reservation transaction, wherein the new reservationtransaction is pre-loaded with the received reservation data; andwherein the method steps are performed by the server.
 2. The method ofclaim 1 further comprising: the server receiving input from the customercomputer indicative of customer-selection of the link; and the serverpermitting the customer to modify at least one type of the receivedreservation data for the new reservation transaction.
 3. The method ofclaim 2 wherein the permitting step comprises the server permitting thecustomer to modify each type of the received reservation data for thenew reservation transaction.
 4. The method of claim 2 wherein the datacommunicating step comprises the server providing data to the customercomputer for a website page to be displayed on the customer computer,the link being for display on the website page.
 5. The method of claim 4wherein the website page comprises a confirmation page for the bookedreservation transaction.
 6. The method of claim 5 further comprising: inresponse to the server receiving the input indicative ofcustomer-selection of the link, the server (1) providing data to thecustomer computer for a verify page for the new reservation transaction,the verify page to be displayed on the customer computer, and (2)automatically populating the verify page with the pre-loaded reservationdata, the verify page being configured to accept modification by thecustomer of the pre-loaded reservation data.
 7. The method of claim 6wherein the pre-loaded reservation data comprises all of the reservationdata for the booked reservation transaction.
 8. The method of claim 2further comprising: the server receiving modification data from thecustomer computer; and the server booking the new reservationtransaction in response to a combination of the received reservationdata and the received modification data.
 9. An apparatus for processinga rental vehicle reservation transaction with a customer computer, theapparatus comprising: a server configured for access by a customercomputer via a network, the server configured to: receive reservationdata from the customer computer; book a reservation transaction inaccordance with the received reservation data; and communicate data tothe customer computer for display thereon after the reservationtransaction has been booked, wherein the communicated data includes alink that is selectable by the customer to create a new reservationtransaction, wherein the new reservation transaction is pre-loaded withthe received reservation data.
 10. The apparatus of claim 9 wherein theserver is further configured to: receive input from the customercomputer indicative of customer-selection of the link; and permit thecustomer to modify at least one type of the received reservation datafor the new reservation transaction.
 11. The apparatus of claim 10wherein the server is further configured to permit the customer tomodify each type of the received reservation data for the newreservation transaction.
 12. The apparatus of claim 10 wherein theserver is further configured to communicate the data to the customercomputer by providing data to the customer computer for a website pageto be displayed on the customer computer, the link being for display onthe website page.
 13. The apparatus of claim 12 wherein the website pagecomprises a confirmation page for the booked reservation transaction.14. The apparatus of claim 13 wherein the server is further configuredto: in response to receipt of the input indicative of customer-selectionof the link, (1) provide data to the customer computer for a verify pagefor the new reservation transaction, the verify page to be displayed onthe customer computer, and (2) automatically populate the verify pagewith the pre-loaded reservation data, the verify page being configuredto accept modification by the customer of the pre-loaded reservationdata.
 15. The apparatus of claim 14 wherein the pre-loaded reservationdata comprises all of the reservation data for the booked reservationtransaction.
 16. The apparatus of claim 10 wherein the server is furtherconfigured to: receive modification data from the customer computer; andbook the new reservation transaction in response to a combination of thereceived reservation data and the received modification data.
 17. Anapparatus comprising: a server configured for access by a customercomputer via a network, the server configured to: interact with thecustomer computer to receive a plurality of data values for creating afirst rental vehicle reservation; provide data to the customer computerfor populating a confirmation screen for display on the customercomputer, the confirmation screen being configured to communicate to thecustomer that the first rental vehicle reservation has been created, theconfirmation screen including a customer-selectable option to create asecond rental vehicle reservation based on the first rental vehiclereservation; receive a selection by the customer of thecustomer-selectable option to initiate a creation of a second rentalvehicle reservation based on the first rental vehicle reservation; andin response to the received selection by the customer of thecustomer-selectable option to initiate creation of a second rentalvehicle reservation based on the first rental vehicle reservation,provide additional data to the customer computer for automaticallypopulating a verify screen for display on the customer computer with aplurality of data values from the first rental vehicle reservation, theverify screen configured with a customer-selectable option to create thesecond rental vehicle reservation; receive data from the customercomputer indicative of a selection by the customer of thecustomer-selectable option to create the second rental vehiclereservation; and in response to the received selection by the customerof the customer-selectable option to create the second rental vehiclereservation, create the second rental vehicle reservation in accordancewith the data values of the verify screen.
 18. The apparatus of claim 17wherein the server is further configured to provide a website for accessby the customer computer, the website comprising a plurality of webpages for access by the customer computer via the network, the pluralityof web pages including a web page for the confirmation screen and a webpage for the another screen.
 19. The apparatus of claim 17 wherein theserver is further configured to automatically populate the verify screensuch that the customer is permitted to create the second rental vehiclereservation through selection of the customer-selectable option tocreate the second rental vehicle reservation without an entry by thecustomer of an additional data value for the second rental vehiclereservation.
 20. The apparatus of claim 17 wherein the server is furtherconfigured to receive input from the customer computer for modifying thedata values automatically populated into the verify screen.
 21. Theapparatus of claim 17 wherein the automatically populated data valuescomprise renter information, a vehicle type, and a branch location forthe reservation.